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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Box Patent Application 

Assistant Commissioner for Patents 

Washington, O.C. 20231 

NEW APPLICATION TRANSMITTAL 

Transmitted herewfth for filing is the patent application of 
lnventor(s); 


Janne PARANTAINEN 
Mlka FORSSELL 


WARNING: 37 C.F.R § 1.41(^) points out: 

'(^ A patent is appEed for in the name or names of ttie actual inventor or inventors. 

'(1) The inventorship of a nonprovisional application is that kiventotship set forth in the oath or 
declaration as prescribed by § 1.63, except as prodded for in § 1.S3(d)(4} and § 1.63(d). If an 
oath or declaration as prescribed by § 1.63 is not Sled during the penderxy of a nonprovrskm^ 
appBcadon. the inventorship is that inventorship set forth in the appBcation pap 
io§ 1£3ft^ unless a petition under this paragraph acooinparuedt^ the fee set forth in § 1.170 
is fUed supplying or changing the name or names of the inventor or inventors.' 

For (title): Method and Arrangement for Transferring Information in a Packet 
Radio Service with Application-Based Choice of Release Mode 


CERTIFiCATlON UNDER 37 CJ^JR. 1.10* 
Express Mag label number Is mmndmtoty.) 
(Express Maff eermcathn bt optiooaL) 

i hereby certify that this New Application Transmittal and the documents referred to as attached therein are being 

rt«.Tir«it«vHv>nthfhfttiftit«¥<»afa^P(Y«rfat<?ftf^ February 4, 2000 , in an envefope 

as "Express Mail Post Office to Addressee," mailing Labe) Nuniber F T, 391 1 ?7?n9TTt; , ad- 
dressed to the: Assistant Commissioner for Patents, Washington. D.C. 20231. 

Judith Schick 


(<ype or print name of 



of person mailing paper 

WARNING: Certificate of mailing (Jr/sf class) or facsimHetransmission procedures of 37 C.F.R 1.8 cannot be 
used to obtain a date of mailing or transmission for this correspondence. 

"WARNING: Each paper or fee filed by 'Express Mail' must have tfw number of tfye 'Express MaH' mailing label 
placed thereon prior to maiting. 37 C.F.R. 1.10^). 

'Since the filing of correspondence under § 1. 10 without the Express Mail mailing label thereon 
is an oversight that can be avoided by the exercise of reasonable care, requests for waiver of this 
requirement wiB not be granted on petition. ' Notice of Oct 24, 1996, 60 Fed. Reg. 56,439, at 56,442. 
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1. Type of Application 

This new applicatfon is for a(n) 

(check one appUcattte item below) 

H Original (nonproviaonaO 

□ Design 
□ Plant 

WARNING: Do not use this tmismM^ k>r a compMon n lha of an Int^^ 

aS.a 371(cj(^ unless the kttemational ApfjScation k being «edas « cSviaonal. continuation or 
oorninuation-ln-paft appScx^on. 
WARMNGz Do not use this ttansnvttal for die mng of a provisional appBcatio^ 
NOTE: HoneoftheMowk^3kemsapply.thencomphteandattachADOEDPAGESF^ 

TRAJ^OTAL WHERE BENBTT OF A PRIOR OS. APPLICATION CLAIMED and a NOTIFICATION 
IN PARB^ APPUCATKXi OF THE FlUNG OF THIS CON7mJATK)N APPUCATK)N. ■ 

□ C^iskxial. 

□ Continuation. 

□ Continuation-in-part (C-l-P). 

2. Benefit of Prior Appllcation(s) (35 U.S.C. 119(e), 120, or 121) 

America. ki order form nonpmi>ishnalapp6catk)n to dabnlh^ 
/iofVfo*«sfofMrf appficatfon Of eop^ 

Ametk:a, each ptforappScathn must name as mtkwenior at least o^ 
nonproviskxialapp/hatixi and Oscfose the named kivento^ 
of the later niednonp(9/kdonalapp6calionkiihe manner proMed^ 
112. Each prior appScaidon must also be: 

(9 An intemation^ appScathn entided to a Sling date in accordance with PCT Article 11 and 
designating the United States of America: or 

^ Convlete as set forth in § 1£1(b}: or 

m Entitled to a mng date as set forth in § 1.S3(b)or§ 1.S3(d} and include the basic filing fee set 
forth in § 1.16: or 

(iv) Entitled to a Oing date as set forth in § 1.53^) and have paid ther^n the processing and retention 
fee set forth in § 1.21& vnthin the time period set forth in § J.53ffl- 

37C.F.R. § 1.78faX1). 

NOTE: If the new application bektgtmnsamed is a di>^ional. continuation or a continuation-in-part 

case, or where the parent case is an International AfHiUcation whfoh designated the U.S.. orbenetit 
of a prior pfovi^onii application is claimed, then che(* the following item and cooipletea^ 
ADDED PAGES FOR NEW APPLICATION TRANSMtnAL WHERE BENEFIT OF PRIOR U.S APPUCA- 
TION(S} CLAIMED. 

WARNING: If an application claims the benefit of the fiBng date of an eariier Sled application under 35 U.S.C. 

120, 121 or 365(<^. the 2(>-yeartenn of that appScationi^ be based upon the mng date of the 
eariiest U.S. application that tfie application makes reference to under 35 US.C. 120. 121 or 3G5(c}. 
(35 U.S.C. 1S4(a){^ does not take into account, for the deteanination of the patent term, any 
application on wtuch priority is claimed under 35 U.S.C. 119. 365(^ or 365^ For a c-i-p 
application. appScant should review whetiter any daim in the patent that win issue is supported 
by an eariier afviTtcation and. if not. the appScant should consider canceling tiie reference to the 
eariier tiled application. The tean of a patent is not based on a dwm-by-daim appmach. See Notice 
of April 14. 1995. 60 Fed. Reg. 20.195, at 20.205. 
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WARNING: When the last day o1 pendefKy of a pm»nsionai appli^^ 

holiday within the District of Columtiia. any nonprwisional application daMng benefit of the 
provisional application must be filed prior to the Saturday. Sunday, or Federal holiday within the 
District of Columbia. See 37 CFJl § 1.78(a)(^. 

□ The new application being transmitted daims the benefit of prior U.S. applica- 
tion(s). Enclosed are ADDED PAGES FOR NEW APPUCATKDN TRANSMnTAL 
WHERE BENEFIT OF PRIOR U.S. APPUCAT10N(S) CLAIMED. 

3. Papers Enclosed 

A- Required for filing date under 37 C.F.R. § 1.53(b) (Regular) or 37 C.F.R. § 1.153 
(Design) Application 

37 

Pages of specification 

— Pages of claims 
_i3_ Sheets of drawing 

WARNING: iX) NOT submit original dra¥irings. A high qu^ copy of the drawings should be suppTied 

fUngm patent application. The drawings that are submitted to the Office must be on strong, white, 
smooth, and non-shiny paper md meet the standards acconUng to § 1M. If cotrecfions to the 
drawings are necessary, they should be made to ttie original drawing and a high-quality copy of 
the comctod original drawing Ihenaubmittod to the Offioa. Only one copy is mquirad or d 
Forcommentsonpmposedthen-new37Cf7i1M.seeNodceofMan:h9. 1988 (1990 0.a 57-^ 
NOTE: 'klentifjfmg io<Sda, if provkied, ^nM inckide the appHcation nunri^ 

inventor's name, docket nua^sef (if atiyi, and the name and telephone numijer of a person to c^ if 
the Office is unable to match the drawings to the proper application. This information should tie placed 
on the back <d ead} she^ of drawing a thmimum distance of IJScm. (5/8 inch) down from the top 
of the p^ . . .'37 CJ^Jl 1.84(c^. 

(comf^e the fdlownng, if applicable) 

□ The enclosed drawing(s) are photograph(s). and there is also attached a 
-PETITION TO ACCEPT PHOTOGRAPHS) AS DRAWING(S).- 37 C.F.R. 1 .84(b). 

□ formal 

□ informal 

B. Other Papers Enclosed 

Pages of declaration and power of attorney 

Pages of abstract 

Other 

4. Additional papers enclosed 

□ Amendment to claims 

□ Cancel in this applications claims before 

cdculating the filing fee. (At least one original independent claim must be 
retained for filing purposes.) 

□ Add the claims shown on the attached amendment. (Claims added have 
been numbered consecutively following the highest numbered original 
claims.) 

□ Preliminary Amendment 

□ Information Disclosure Statement (37 C.F.R. 1.98) 

□ Forni PTO-1449 (PTO/SB/08A and 08B) 

□ Citations 
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□ Declaration of Biological Deposit 

□ Submission of "Sequence Usting," computer readable copy and/or amendment 
pertaining thereto for biotechnology invention containing nucleotide and/or 
amino acid sequence. 

□ Authorization of Attomey(s) to Accept and Follow Instnjctions from Representa- 
tive 

□ Specif Comments 

□ Other 

6. Declaration or oath fmciuding power of attome)^ 

NOTE: A eK>xxrt»Mi dttcbfBtkxi k not requii^ 
the p(W nofvmvi^on^ appScation oeyrta^ 

by all or fewer than a« the ki^ots named ki the prmr appScatk^ there is no new matter in the 

appecatk)nbeingS9<lmdacopyof^axeajteddedata^ 

the agnatum or an Micalion thereon that H was agned) is s»±mi^ 

a statement mquesengdiihSon ot the names of person^ who are not inventon 
t}eingeh<Ltf the dedatation in the prktrapplicaSon was filed un^ 1.47. then a copy of that 
dedarationmuat>»aedaoooa^)anedl»yacopyof^dedaongran^S 1.47statusor.ifanonsigning 
person under § 1.47 has aiAsequentfy joined in a prnr applk^ation. then a copy of ^ 
executed dedantion must be See 37 CLF.R §§ 1.63(d)aH^- 
NOTB AdedantkxilMtocomplataanappScalMXimustbeamc^ 

is dk9cM. kion^aach imantorbyMnameMuding famSynameandat least one ^ven name, without 
abbiwiaeon together with any o»ier given name or inland the reader 
country or c^bansfilp of each inventor, and stats whether the inventor is a sole or 

CJ'Jl § 1.63(aX1)-(4) 

□ Enclosed 
Executed by 

(check all applicable ttoxes) 

□ inventof(s). 

□ legal representative of inventor(s). 
37CFR 1.42 or 1.43. 

O joint inventor or person showing a proprietary 
interest on tiehsdf of inventor who refused to sign 
or cannot be reached. 

□ This is the petition required by 37 CFR 1 .47 and the statement 
required by 37 CFR 1.47 is also attached. See item 13 below for 
fee. 

S! Not Enclosed. 

NOTE- Where the ffing is a completkm in the U.S. of an International Application or where the completion of 
me as. application contains suljject matter in addition to the mtemational Application, the application 
may be treated as a continuation or continuation-in-part, as the case may be. utilizing ADDED PAGE 
FOR NEW APPUCAVON TRAJ^fTTAL WHERE BENEf^ OF PRIOR U.S. APPLICAVON CLAIMED. 

□ Application is made by a person auttiorized under 37 C.F.R. 1 .41 (c) on behalf 
of sdi the above named inventor(s). 

(The declamtion or oath, along with the surcharge required by 37 CFR 1.16(e) 
can be filed subsequently). 

□ Showing that the filing is authorized. 

(not required unless called into question. 37 CFR 1.41(d)) 
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6. Inventorship Statement 

WARNING: If the named inventors ate each not the inventors of alt the daims an explanation, including the 
ovmership of the various claims at the time the last claimed invention was made, should be 
SiAmitted. 

The inventorship for all the claims in this application are: 

□ The same. 

or 

□ Not the same. An explanation, including the ownership of the various claims at 
the time the last claimed invention was made, 

□ is submitted. 

□ will be submitted. 

7. Language 

NOTE: An application including a signed oath or declaration may be filed in a language other than English. 
An English translation of the non-English language application and the processing fee of $130.00 
requmd by 37 CFB 1.17(k)is requued to be Oed with the application, or within such time as may be 
set by ^ OfSfce. 37 CFR 1.S2(d). 

® English 

□ Non-English 

□ The attached translation includes a statement that the translation is accu- 
rate. 37 C.F.R. 1.52(d). 

8. Assignment 

„ . . X ^ ■ * Nokia Mobile Phones LTD 

0 An assignment of the invention to — 


n is attached. A separate O "COVER SHEET FOR ASSIGNMETJT (pOCU- 
MENT) ACCOMPANYING NEW PATENT APPUCATION" or □ FORM PTO 
1595 is also attached. 

0 will follow. 

NOTE: 'If an assignment is subrtMed with a new appScaSon, send two separata letters^ine^ the apf^ 

and one for the assignment' Notice of May 4, 1990 (1114 O.G. 77-78). 
WARNING: A newly exeoJted'CERmiCATE UNDER 37 CFR 3.73(b)' must be fded when a continuation-in-part 
3pplication isfHedbyan assignee. Notice of April 30, 1993. 1150 O.G. 62-64. 
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9. Certified Copy 

Certffied copyfies) of application(s) 


Country 

Appln. No. 

RIed 

Country 

ApplfL No. 

Rted 

Courrtiy 

Appln. No. 

Filed 


from wtiich priority is claimed 

□ is (are) attached. 

□ will follow. 


NOTE: The fongign application kxming the basis for the daim for priority must be refeired to in the oath or 
declaration. 37 CFR 1.S5(a) and 1.63. 

NOTE: This item is for any foreign priority for which the application being Sled rSrecdy relates. If any parent 
UJS. t^ipfication or Intomational AppScation tmm which this appScation claims benefit under 35 US.C. 
120 is itself entitled to priority from a prior foreign application, then complete item 18 on the ADDED 
PAGES FOR NEW APPUCATm TRANSMITTAL WHERE BENEFIT OF PRim U.S. APPUCATION(S) 
CLAIMED. 

10. Fee Cakxitation {37 C.F.R. 1.16) 
A. @ Regular application 


CLAIMS AS RLED 

Numt)er filed 

Number Extra 


Rate 

Basic Fee 
37 C.F.R. 1.16(a) 

$'690.00 

Total 48 

aaims (37 CFR 1.16(c)) - 20 

28 

X 

$ 18.00 

504.00 

Independent i 

Claims (37 CFR 1.16(b)) - 3 

0 

X 

$ 78.00 


Multiple dependent claim(s), 
if any (37 CFR 1.16(d)) 


+ 

$260.00 



□ Amendment canceling extra claims is enclosed. 

□ Amendment deleting multiple-dependencies is enclosed. 

□ Fee for extra claims is not t>eing paid at this time. 

NOTE: If the fees for extra claims are not paid on filing they must be paid or tfte claims cancelled by amendment, 
prior to tfie expiration of the Hme period set for response by the Patent and Trademark Office in any 
notice of fee deficiency. 37 CFR 1. 16(d). 

Filing Fee Calculation $ 1,194.00 

B. □ Design application 

$310.00 

Filing Fee Calculation $ 

C. □ Plant application 

$480.00 -37 CFR 1.16(g)) 

Filing fee calculation $ 

(Application Transmittal [4-11 — page 6 of 11) 
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11. Small Entity Statefnent(s) 

□ Statefnent{s) that this is a filing by a small entity under 37 CFR 1 .9 and 1 .27 
is (are) attached. 

WARNING: Status as a smaH entity must tie sfxdticaffy established in each application or patent in ¥/hich 
the status is avalable and desired. Status as a small entity in one application or patent does not 
affect any ottter application or patent, including applications or patents which are directiy or 
kxSrectfy dependent upon tiK^vBcation or patent in wfMt the ^atus has been es The 
teGmg of m apfOcaSon under § as a continuation, divi^. or continuation-in-pait(induding 
a continued prosecution application under § l^d)), or the filing of a reissue appScation requires 
a new determination as to continued entitiement to smaS entity st^us for tiK continuing or r&ssue 
appTication. A nonprovisionat apf^cation claiming benefit under 35 U.S.C. 1 19(e}. 120, 121, or 
365(c^ of a prior application, or a reissue af^ication may rely on a statement Sled in tiie prior 
application or in tt^ patent if the nonpmvisional application or the reissue application includes a 
reference to the statement in the prior application or in the patent or includes a copy of the 
statementin tiie prior application or in the patent and status as a smalt entity is stOI proper and 
desired. The payment of tite small entity l)asic statutory filing fee will t)e treated as such a reference 
for purposes of this section.' 37 C.F.R. § 1.28(aX2}. 

(<X)mplete the following, if applicable) 

□ Status as a small entity was claimed in prior application 

/ . filed on , from which benefit 

is being claimed for this application under 

35 U.S.C. □ 119(e). 

□ 120. 

□ 121. 

□ 365(c). 

and which status as a small entity is still proper and desired. 
□ A copy of the statement In the prior application is included. 
Rling Fee Calculation (50% of A, B or C above) 
$ 

NOTE: Any excess afthefuUfee paid w9l be refunded if sma/l entitiy status is established and a refund request 
are filed within 2 mortths of the date of timely payment of a full fee. The two-month period is not 
extendable under § 1.136. 37 CfR 1.28^. 

12. Request for International-Type Search (37 C.F.R. 1.104(d)) 

(complete, if applicable) 

□ Please prepare an international-type search report for this application at the time 
when national examination on ^e merits takes place. 
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13. Fee Payment Being Made at This Time 

[3 Not Enclosed 

@ No filing fee is to be paid at this time. 

(TNs and the surcharge required by 37 C.F.R. 1.16(e) can be paid subse- 
quently.) 

□ Enclosed 

□ Filing fee $ 

□ Recording assignment 
<$40.00; 37 C.F.R. 1.21(h)) 

(See attached "COVER SHEET FOR 
ASSIGNMENT ACCOMPANYING NEW 

APPLICATION-.) $ 

□ Petition fee for filing by ottier than all the 
inventors or perscwi on behalf of the inventor 
wtiere inventor refused to sign or cannot be 
reached 

($130.00; 37 C.F.R. 1.47 and 1.17(i)) $ 

O For processing an application with a 
specification in 
a non-English language 

($130.00; 37 C.F.R. 1.52(d) and 1.1 7(k)) $ 

O Processing and retention fee 

($130.00; 37 C.F.R. 1.53(d) and 1.21(1)) $ 

O Fee for Intemational-t^ search report 

($40.00; 37 C.F.R. 1.21(e)) $ 

NOTE: 37C^1Jtl(ftestabeshesatoekirpnxxssingandret^ninganyeppl^^ 
to comfihte the app6caik>n pursuant to 37 (^1.53(1^^ 

and 1.78(s)(1). indicate that in ader to obtain the benefit of a prior U.S. application, either the basic 
ming foe must tie paid, or the processing and netention fee of § 1.21(0 must be paid, wittiin 1 year fmtn 
notification tmder § 53(f). 

Total fees enclosed $ 

14. Method of Payment of Fees 

□ Check in the amount of $ 


□ Charge Account No. in the amount of 

$ 

A duplicate of this transmittal is attached. 
NOTE: Fees should be itemized in such a manner that it is dear for which purpose the fees are paid. 37 CFR 
1.22(b). 
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15. Authorization to Charge Additional Fees 

WARNING: If no fees are to tx) paid on filing, the fo#ovwig items should not be completed. 
WARNING: Accuratefy count claims. espedaOy mulGpfe dependent daims. to avwd unexpected high charges, 
if extra da/m chaig&s are authonzed 
□ The Commissioner is hereby authorized to charge the following additional fees 
by this paper and during the entire pendency of tfiis application to Account No. 


□ 37 C.F.R. 1.16(a), (f) or (g) (filing fees) 

□ 37 C.F.R. 1.16(b). (c) and (d) ftjresentation of extfB claims) 

NOTE; eecat^oadWtiboa/ fees /or excess or muftp^ 

must only be pa«/ or these daims canceHed by amendment prior to the expiration of the time period 
set for response by the PTO in any notice of fee deficiency (37 CFR 1.16(d)). it might be best not to 
authorize the PTO to charge additional dalm fees, except possOtly when dealing with amendments after 
final action. 

□ 37 C.F,R. 1 .16(e) (surcharge for filing the basic filing fee and/or declaration 
on a date later tiian the filing date of ttie application) 

□ 37 CF.R. §§ 1.17(aK1H5) (extension fees pursuant to § 1.136(a)). 

□ 37 C.F.R- 1.17 (application processing fees) 

NOTE: '. . AwtiOanmque^maybesiAxnittedinmapfiticationlh^ 

or Mure reply, requiring a petition ioranextensionoflimeunderthisparagraph forits tim^ submission, 
as incorpofaUng a petition for extension of time for the appropriate length of time. An authorization to 
chatgeaUmquirad fees, fees under § 1.17. or aiB required extension of time fees will be treated as a 
constnKtive p^ition for an extension ta time in any concunent or hilum reply requiring a petition ^ 
anextanaonof tinte under ^paragraph for its tknefysubnwssiaa. Submission^ 
§ l.ljfefwa also be treated as a constructive petition k)r an extsttsion of time in any concuwent reply 
requiring e petition for an ei^nsion of tinK under ^paragr^ for its tintely submission." 37 C.F.R. 
§ 1.136m). 

□ 37 C.F.R. 1.18 C'ssue fee at or before mailing of Notice of Allowance, 
pursuant to 37 CF.R. 1.311^)) 

NOTE: Where an autiHtrization to charge the issue fee to « deposft account has t>een filed before the mailing 
of a Notice of AMowanoe. ttte issue fee wW be autontatically charged to the deposit account at tiie time 
of mailing the notice of affowance. 37 CFfl 1.311{b). 

NOTE: 37 CFR 1.28(b) requires 'Notification of any change in status restMng in toss of entitlement to small 
entity status must be fOed m tiie application . . . prior to paying, or at the time of paying. . . . the issue 
fee. . . ." From the wording of 37 CFR 1.28p), ^ notification of change of status must be made even 
if the fee is paid as 'other titan a small entity" and (b) no notification is required if the change is to 
another smaU entity. 
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16. Instructions as to Oveipayment 

NOTE: : . . Amounts of twentySve doUars or less witt not be rotumed unless specXcaBy mqoested within 
a masonic tinu. nor ¥^ the payer be notiGed of such anKXin^^ 

be returned by check or. if requested, by credit to a deposit account' 37 C.FJi. § 1:26(a). 

□ Credit Account No. . 

□ Refund 


Reg. No. 


27,550 



Tel. No. (203 ) 261-1234 


(type or print name of attorney 
WARE, FRESSOLA, VAN DER SLUYS & ADOLPHSON LLP 

755 Main Street, Building Five 


Customer No. 004955 


P.O. Address 
PO Box 224 
Monroe, CT 06468 
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□ Incorporation by reference of added pages 

(check the following Hem if the application in this transmittsJ daims the t>enem of 
prior U.S. application(s) including an international application entering the U.S. 
stage as a contirujation, divisional or Ol-P application) and complete and attach 
the ADDED PAGES FOR NEW APPLICATION TRANSMnTAL WHERE BENEFIT OF 
PRIOR U.S. APPUCAT10N(S) CLAIMED) 

□ PkJS Ackled Pages for New Application Transmittal Where Benefit of Prior U.S. 
Application{s) Claimed 

Number of pages added 

□ Plus Added Pages for Papers Refenred to In Item 4 Above 

Number of pages added 

□ Plus added pages deleting names of inventor(s) named In prior application(s) 
who Is/are no longer lnventof<s) of the sut>ject matter claimed in this application. 

Number erf pages added 

□ Plus "Assignment Cover Letter Accompanying New Application" 

Number of pages added 

m statement Where No Further Pages Added 

Of no further ps^ form a part of this Transmittal, then end this Transmittal with 
this page and check the following item) 

(3 This transmittal ends with ttiis page. 
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METHOD AND ARRANGEMENT FOR TRANSFERRING INFORMATION 
IN A PACKET RADIO SERVICE WITH APPLICATION-BASED 
CHOICE OF RELEASE MODE 

Technical Field 

The present invention relates generally to a method and arrangement for 
transferring information in a packet radio service. It is particularly directed to 
transferring data, such as voice, telnet, or web browsing in certain instances 
where there is a traffic type that have inactive periods between active 
transmissions. The invention is particularly directed to application based choice 
of Temporary Block Flow (TBF) setup and release. 

Background of the Art 

The phrase "mobile telecommunications system" generally refers to any 
telecommunication system which enables a wireless communication connection 
between a mobile station (MS) and the fixed parts of the system when the user 
of the mobile station is moving within the service area of the system. A typical 
mobile communication system is a Public Land Mobile Network (PLMN). The 
majority of mobile telecommunication systems in use to date belong to second 
generation systems such as the well-known Global System for Mobile 
Telecommunications (GSM) system commonly used in Europe and elsewhere, 
including the United States. The present invention applies particulady to general 
packet radio service (GPRS) which forms part of the architecture of Universal 
Mobile Telecommunications System (UMTS), a third generation system which 
merges mobile telephony with data communications, especially those for use 
with the global communications network commonly called the Internet. Data 
communications can also include multi-media services associated with the 
Internet. Such services, including Internet real-time services, have gained 
popularity over the last several years. Internet protocol (IP) telephony and 
different streaming applications such as audio streaming and video streaming 
are already quite common on the Internet. In addition, the demand for wireless 
access to these real-time services is expected to grow at an exponential rate 
over the near term. Packet switched wireless networks such as GPRS are 
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designed to provide data services such as Internet services, in a cost effective 
manner. In GPRS, the channels are not dedicated to one user on a continuous 
basis but are shared between multiple users. This procedure facilitates efficient 
data multiplexing. However, GPRS was not originally designed for transferring 
delay sensitive real-time data, such as IP telephony sessions. In general, it was 
not specifically designed for applications that transfer data that have relatively 
short inactive periods (no data to be transmitted) between active data transfer 
periods. For this reason, GPRS currently contains various technical solutions 
that only partially meet the requirements with regard to real-time traffic. As 
defined herein, the phrase "specific traffic class" corresponds to data transfer 
for which the network resources are not to be released during possible inactive 
periods between active periods. An example of such is a conversational voice 
connection or an interactive connection e.g. telnet. It is very beneficial in 
UMTS, but it can also be used in interactive data transfer applications, e.g. 
telnet. 

In order to better understand the problems of prior art solutions as well as 
the idea of the present invention, the structure of a third generation digital 
cellular radio system is first described and GPRS is then described in more 
detail. 

Figure 1 a shows a version of a future cellular radio system which is not 
entirely new with respect to the known GSM system, but which nevertheless 
includes known elements and new elements. The terminals are connected to 
the radio access network (RAN) which includes the base stations and the base 
station controllers. The core network of a cellular radio system comprises 
mobile services switching centers (MSCs), other network elements (in GSM, e.g. 
SGSN and GGSN, that is, Serving GPRS Support Node and Gateway GPRS 
Support Node) and related transmission systems. According to GSM + 
specifications developed from GSM, the core network can also provide new 
services. 

A new technology. Enhanced Data Rates for GSM Evolution (EDGE) will 
increase the network capacity and data access rates of both circuit switching 
and packet switching so as to meet expected demands of wireless multimedia 
applications and more market deployment. The transmission speed of circuit 
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switching is increasing with the introduction of High Speed Circuit Switched 
Data (HSCSD) while packet data rates are being provided by General Packet 
Radio Services (GPRS). EDGE, a new radio interface technology with enhanced 
modulation, increases the HSCSD and GPRS data rates by up to three fold. 
EDGE modulation increases the data throughput provided by the packet 
switched service even over 400 kbit/s per carrier. Similarly, the data rates of 
circuit switched data can be increased, or existing data rates can be achieved 
using fewer timeslots, saving capacity. Accordingly, these higher speed data 
services are referred to as EGPRS (Enhanced GPRS) and ECSD (Enhanced Circuit 
Switched Data). 

This combination of EGPRS and HSCSD in a network is known as 
GERAN, GSM EDGE Radio Access Network. Figure 1c illustrates GERAN, 
including the EGPRS and ECSD branches of the network. Officially GERAN is a 
term used to describe a GSM and EDGE based 200 kHz radio access network. 
The GERAN is based on GSM/EDGE release 99 and covers all new features for 
GSM Release 2000 and subsequent releases, with full backward compatibility to 
previous releases. 

In GERAN, packet voice service using e.g. AMR (Adaptive Multirate 
Codec) may be implemented. Such services represent a type of real-time 
application that typically has periods of silence (no speech). Procedures for 
handling such applications are required. 

Figure lb shows an architecture of a general packet radio service (GPRS). 
As explained, earlier GPRS is a new service that is currently based on the GSM 
system but the general principles discussed herein can be applied to GRAN 
(General Radio Access Network). GPRS is one of the objects of the 
standardization work of the GSM phase 2+ and UMTS at the ETSI (European 
Telecommunications Standard Institute) and 3GPP. The GPRS operational 
environment comprises one or more subnetwork service areas, which are 
interconnected by a GPRS backbone network. A subnetwork comprises a 
number of packet data service nodes (SN), which in this application will be 
referred to as serving GPRS support nodes (SGSN) 153, each of which is 
connected to the mobile telecommunications system (typically to a base station 
through an interworking unit) in such a way that it can provide a packet service 
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for mobile data terminals 151 via several base stations 152, i.e. cells. The 
intermediate mobile communication network provides packet-switched data 
transmission between a support node and mobile data terminals 151. Different 
subnetworks are in turn connected to an external data network, e.g. to a Public 
Data Network (PDN) 155, via GPRS gateway support nodes GGSN 154. The 
GPRS service allows the provision of packet data transmission between mobile 
data terminals and external data networks when the appropriate parts of a 
mobile telecommunications system function as an access network. 

In order to access the GPRS services, a mobile station first makes its 
presence known to the network by performing a GPRS attachment. This 
operation establishes a logical link between the mobile station and the SGSN, 
and makes the mobile station available for SMS (Short Message Services) 158, 
159, over GPRS, paging via SGSN, and notification of incoming GPRS data. 
More particularly, when the mobile station attaches to the GPRS network, i.e. in 
a GPRS attachment procedure, the SGSN creates a mobility management 
context {MM context). Also, the authentication of the user is carried out by the 
SGSN in the GPRS attachment procedure. In order to send and receive GPRS 
data, the MS activates the packet data address that it desires to use by 
requesting a PDP activation procedure (Packet Data Protocol). This operation 
makes the mobile station known in the corresponding GGSN, and interworking 
with external data networks can commence. More particularly, a PDP context is 
created in the mobile station and the GGSN and the SGSN. The packet data 
protocol context defines different data transmission parameters, such as the 
PDP type (e.g. X.25 or IP), the PDP address (e.g. X.121 address), the Quality of 
Service (QoS) and the NSAPI (Network Service Access Point Identifier). The MS 
activates the PDP context with a specific message. Activate PDP Context 
Request, in which it gives information on the TLLI, the PDP type, the PDP 
address, the required QoS and the NSAPI, and optionally the access point name 
(APN). 

Figure lb also shows the following GSM functional blocks; Mobile 
Switching Center (MSC)/Visitor Location Register (VLR) 160, Home Location 
Register (HLR) 157 and Equipment Identity Register (EIR) 161. The GPRS 
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system is usually also connected to other Public Land Mobile Networks (PLMN) 
156. 

Functions applying digital data transmission protocols are usually 
described as a stack according to the OSI (Open Systems Interface) model, 
5 where the tasks of the various layers of the stack, as well as data transmission 
between the layers, are exactly defined. In the GSM system phase 2 + , which 
is observed herein as an example of a digital wireless data transmission system, 
there are five operational layers defined. 

The mobile station MS must include a higher-level control protocol 212 
10 and a protocol 213 for serving higher-level applications, of which the former 
communicates with the RRC layer 206 in order to realize control functions 
connected to data transmission connections, and the latter communicates 
i directly with the LLC layer 204 in order to transmit such data that directly 
: serves the user (for instance digitally encoded speech), in a mobile station of 
is the GSM system, the blocks 212 and 213 are included in the above-mentioned 
3 MM layer. 

5 In GPRS, a Temporary Block Flow (TBF) is created for transferring data 

'i packets on a packet data channel. The TBF is a physical connection used by 

i the two Radio Resource (RR) peer entities to support the unidirectional transfer 

20 of Logical Link Control (LLC) Packet Data Units (PDU) on packet data physical 
1 channels. The TBF is normally always released when there is no data to be 

transmitted. Such a release creates a problem in voice services and other real- 
time services such as streaming audio or video when silent periods can occur 
from time to time. It is also a problem in general where the application has 
25 relatively short inactive periods between active transmission periods. Such 
applications can include telnet and web browsing. During these silent or 
"passive" periods no data is transferred and the TBF is thus normally released. 
The TBF setup procedure is likely to be too long in order to be set up quickly 
enough when the active period resumes, which results in undesirable voice 
30 quality. 

An example of the resource allocation in the GPRS of the current GSM 
Phase 2+ specification is next described in more detail. 
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In the GSM Phase 2+ the uplink resource allocation is currently specified 
as follows: The Mobile Station (MS) requests uplink radio resources by sending 
a PACKET CHANNEL REQUEST message to the network. Various access type 
values are specified for the request message. For data transfer 'one phase 
access', 'two phase access' and 'short access' type values are defined. Using 
'short access' type value, the MS may request the radio resources to transfer 
only a few RLC data blocks, and therefore it is not applicable for transferring 
continuous data flows. 

When a network receives a PACKET CHANNEL REQUEST message 
indicating one phase access, it may allocate radio resources on one or several 
Packet Data Channels (PDCH). The allocation is based on information included 
in the request message. The following table shows an example for an 1 1 bit 
message content of a PACKET CHANNEL REQUEST message: 
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bits 


11 10 987654321 

Packet Channel Access 

\j m m ni iii iii ^ x -l x 

One Phase Access Request 
<MultislotClass : bit (5) > 
<Priority: bit (3) > 
<RandomBits: bit (3) > 

-1 n n n n "K* T~ "K* 

X uunniipyi-i-J- 

Short Access Request 
<NoOf Blocks: bit (3)> 
<Priority: bit (2) > 
<RandomBits : bit (3)> 

1 lOOOOpprrr 

Two Phase Access Request 
<Priority: bit (2)> 
<RandomBits: bit (3)> 

1 lOOOlrrrrr 

Page Response 
<RandomBits: bit (5) > 

1 lOOlOrrrrr 

Cell Update 
<RandomBits: bit (5)> 

1 lOOllrrrrr 

Mobility Management 
Procedure 

<RandomBits : bit (6)> 

1 lOlOOrrrrr 

Single Block Without TBF 
Establishment 
<RandomBits: bit (5)> 

All others 

Reserved 


An 1 1 bit PACKET CHANNEL REQUEST message indicating one phase 
access has a field of 5 bits describing the multislot class of the mobile station, a 
field of two bits indicating requested priority and a field of three bits describing 
random reference (random mobile station identification information). 
1 5 The following table shows an example for an 8 bit message content of a 

PACKET CHANNEL REQUEST message: 


7 


944-003.003 


bits 


87654321 

Packet Channel Access 

Iratnmmmrr 

One phase Access Request 
<MultislotClass : bit (5) > 
<RandomBits : bit (2)> 

0 Onnnrrr 

Short Access Request 
<NoOf Blocks: bit (3)> 
<Randombits: bit (3)> 

OlOOOrrr 

Two Phase Access Request 
<RandomBits : bit (3)> 

OlOOlrrr 

Page Response 
<RandomBits: bit (3) > 

OlOlOrrr 

Cell Update 
<RandomBits : bit (3) > 

OlOllrrr 

Mobility Management 
Procedure 

<RandomBits: bit (3) > 

OllOOrrr 

Single Block Without TBF 
Establishment 
<RandomBits: bit (3) > 

All others 

Reserved 


An 8 bit Packet Channel Request message indicating one phase access 
has a field of 5 bits describing the nrnultislot class of the nnobile station and a 
field of two bits describing random reference. The information about the 
allocated radio resources is sent to the Mobile Station with a PACKET UPLINK 
15 ASSIGNMENT message. 

When a network receives a PACKET CHANNEL REQUEST message 
indicating two phase access, it may allocate limited radio resource on one 
packet data channel. The allocated radio resources are transmitted to the 
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mobile station with a PACKET UPLINK ASSIGNIVIENT message. After this 
allocation the mobile station transmits a PACKET RESOURCE REQUEST 
message to the network by using the allocated radio resource. The message 
defines more accurately the required radio resources, e.g. requested bandwidth 
and priority, and the radio capability of the mobile station. Based on the 
information received in the PACKET RESOURCE REQUEST message, the 
network may assign one or several packet data channels to the TBF and informs 
the assigned radio resources to the mobile station with a PACKET UPLINK 
ASSIGNMENT message. 

In such a configuration, the request of resources is made using the GPRS 
control channel as an example. There are also other ways of requesting 
resources in case the cell does not include a GPRS control channel (even if it 
supports GPRS). In this case the resource request can be made using a GSM 
control channel. 

In the prior art the uplink radio resource allocation could cause the 
following problems: 

If the priority field included in the PACKET CHANNEL REQUEST and the 
PACKET RESOURCE REQUEST messages does not define the characteristics of 
the data to be transmitted (e.g. delay sensitive real-time traffic), the network 
might not be able to provide the needed radio resources for the MS. Thus, e.g. 
transferring speech using the GPRS might not reach a sufficient quality. 

The default RLC mode is an acknowledged mode in one phase access. 
Since real-time traffic would be transferred using unacknowledged RLC mode, 
two phase access should be used. Using two phase access, additional radio 
resource request information may be given to the network. However, two 
phase access causes additional delay to the channel assignment procedure, 
because the mobile station has to send two request messages to the network 
instead of one. In spite of the additional radio resource request information it is 
not guaranteed that the network is able to provide the needed radio resources 
for the mobile station transferring delay sensitive real-time traffic. 

When allocating radio resources for uplink transfer, downlink radio 
resources cannot be allocated simultaneously, because the downlink Temporary 
Block Flow (TBF) cannot be created without downlink packets. Thus it is 
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possible, when the mobile station is to receive a downlink packet, the network 
is unable to assign radio resources for the transfer of the packet. 

Downlink radio resource allocation is currently specified as follows: 
When the network receives data for a nnobile station which has no assigned 
radio resources and whose cell location is known, the network assigns radio 
resources on one or several packet data channels by transmitting a PACKET 
DOWNLINK ASSIGNMENT message to the mobile station. When the mobile 
station receives the assignment message, it starts listening to the allocated 
packet data channels for Radio Link Control (RLC) data blocks. 

In downlink radio resource allocation, the following problems may arise: 

If information attached to data (coming from the SGSN) does not define 
the characteristics of the data to be transmitted (e.g. delay sensitive real-time 
traffic), the network may not be able to provide the needed downlink radio 
resources for the MS. 

Also if there is a need to transfer e.g. delay sensitive real-time traffic in 
both directions, downlink and uplink, the mobile station may request uplink radio 
resources only when the network assigns sending permission to the mobile 
station. This may cause a delay of a variable amount of time, such as several 
seconds. 

When allocating radio resources for downlink transfer, uplink radio 
resources cannot be allocated simultaneously because the uplink Temporary 
Block Flow cannot be created without uplink packets. Thus it is possible, that 
the mobile station may request uplink radio resources but the network is unable 
to assign the requested radio resources. 

Uplink radio resource deallocation is currently specified as follows: Every 
uplink RLC data block includes a countdown value (CV) field. It is specified in 
reference [1] (see Table 1) that the CV shall be 15 when the mobile station has 
more than BS CV MAX (broadcast parameter) RLC data blocks left to be 
transmitted to the network. Otherwise the mobile station indicates to the 
network the number of remaining RLC data blocks with the CV field. The last 
RLC data block is sent to the network with the CV value set to '0'. Reference 
[1] also defines that once the mobile station has sent a CV value other than 
'15', it shall not enqueue any new RLC data blocks; meaning that the new RLC 

10 


944-003.003 

data blocks shall not be sent during the ongoing TBF. Once the network 
receives RLC data block with the CV field set to '0', the TBF release procedures 
are initiated. 

In uplink radio resource deallocation, the following problems nnay arise: 
If e.g. delay sensitive real-time data is transferred over radio interface 
according to current GPRS rules, the mobile station has to establish several 
TBFs per session, because during the passive periods the mobile station has no 
RLC data blocks to send to the network and thus the CV value '0' terminates 
the uplink TBF. Because the TBF setup procedures takes time, delay sensitive 
traffic cannot be transmitted with good quality. Also, there are no guarantees 
that free radio resources are always available when the mobile station requests 
uplink radio resources. 

Downlink radio resource deallocation is currently specified as follows: 
Every downlink RLC data block includes a Final Block Indicator (FBI) field in the 
RLC header. Reference [1] defines that the network indicates to the mobile 
station the release of the downlink TBF by setting the FBI field to '1'. The 
network sets the FBI field to '1' when it has no more RLC data blocks to send to 
the mobile station. After receiving RLC data block with FBI field set to 'V the 
mobile station shall acknowledge to the network that it has received the FBI 
information. When the network receives the acknowledgement message, the 
TBF is released. 

In downlink radio resource deallocation, the following problems may arise: 
If e.g. delay sensitive real-time traffic is transferred over radio interface 
according to current GPRS rules, the network has to establish several TBFs per 
session, because during the passive periods the network has no RLC data blocks 
to send to the mobile station and thus the FBI value '1' terminates the downlink 
TBF. Also, there are no guarantees that free radio resources are always 
available when the network tries to allocate downlink radio resources. 

Problems also occur in assigning uplink and downlink sending 
permissions: If e.g. delay sensitive real-time data traffic is transferred on packet 
data channel/channels (PDCH), it is not guaranteed that adequate sending 
permissions are given in order to transfer the data, because the current network 


11 


944-003.003 

may not have knowledge about the characteristics of the transferred data (e.g. 
delay sensitive data). 

A further problem with the prior art specification Is related to the feature 
that the network assigns transmission permissions for uplink and downlink 
directions independently, i.e. controls which mobile station receives data next 
and which mobile station may send data next. However, some types of 
application generated data, e.g. delay sensitive data associated with speech, 
have strict delay requirements. Consequently, whenever such a delay sensitive 
data user has something to transmit, it must be able to do so in order to 
maintain an acceptable service level. If more than one user is allocated to the 
same packet data channel it is probable that at some point two or more users 
will need to transmit simultaneously, and just one can be served on the channel. 
In speech conversations a large proportion of the connection time is silence. 
Thus it would be possible to statistically multiplex more than one speech user 
for one packet data channel. The GPRS channel reservation system, however, 
is not elaborate enough to support this need. Therefore only one user of delay 
sensitive data transfer can be allocated for one packet channel, which means 
that the usage of the channel capacity is not optimized. 

When the network notices that a mobile station wants to send e,g, delay 
sensitive data in the uplink direction the network reserves as much uplink 
resources to the mobile station as is requested. This naturally requires that the 
network has the required resources available. Such allocation may mean that 
the packet data channel is dedicated temporarily to a single mobile station in the 
uplink direction. During passive periods in such uplink delay sensitive data 
transfer, the network may assign uplink sending permissions of the allocated 
channels to other mobile stations. Since the mobile station transferring e.g. 
delay sensitive data reserves the uplink capacity of the packet data channel, 
other mobile stations that are allocated to the same packet data channel cannot 
be assigned a sending permission to determine whether they have data to send 
in the uplink direction. Also, if more than one mobile station allocated to the 
same packet data channel needs to send e.g. delay sensitive data at the same 
time, only one can be served. Therefore the network is forced to restrict the 
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number of mobile stations transferring e.g. delay sensitive data according to the 
number of packet data channels in order to provide acceptable service quality. 

RLC/MAC Layer TBF Control 

One technique to resolve these problems is where the physical connection 
of a packet radio service is kept reserved during the passive periods of a session 
yet the same physical resource can still be shared between multiple users. In 
this procedure, a TBF is also kept functional when there is nothing to transfer 
between the mobile station and the network. The procedure in general supports 
traffic types which have inactive periods between active transmission. The 
procedure is especially beneficial for real time services which do not tolerate 
TBF setup delays. 

Thus the network may be informed at the end of an active period, as to 
whether a passive period follows the active period (and therefore the connection 
should not be released since at least one more active period is to follow) or if 
the connection can be released (no more active periods are to follow). The 
network may also be informed as to whether the packet data channel can be 
assigned to other Temporary Block Flows. The information can be transferred 
e.g. on the packet data channel during an active period or on a control channel 
at any time. On the packet data channel the information can be transferred e.g. 
in the MAC header field of a data block. Alternatively a separate signalling 
message can be used. With this information it is possible to keep the created 
Temporary Block Flow available even when there is no data to be transmitted. 
When an active period starts after a passive period, the connection starts using 
the created TBF again, and possible other users of the packet data channel may 
be assigned to other channels. 

In general, the TBF can be controlled using one of a plurality of 
methodologies. Thus TBF can be left on until control information is signalled 
concerning its release or if a maximum hold timer (e.g. up to 10 minutes) 
expires. At such occurrences, the TBF is released. One alternative is that the 
TBF is set up in the MAC layer. A second alternative is that the application 
layer sets the TBF to stay on. A third alternative is that the release of the TBF 
may be placed in the data field in which information of the end is expressed or 
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that a separate data packet is sent (in the data channel), or that a separate data 
packet is sent in the signalling channel, or that a timer is used {the expiration of 
which initiates the release of the TBF). 

In another technique to solve these problems several traffic type (e.g. 
delay sensitive) data flows are allocated to the same packet data channel. On 
an uplink channel, after one mobile station starts to transmit, the other mobile 
stations may be reallocated to other channels immediately or a transmission 
permit can be periodically allocated to the mobile stations so that the mobile 
stations may indicate their willingness to transfer. On a downlink channel, after 
one mobile stations starts to transmit, the other mobile stations may be 
reallocated to other channels immediately as well or the data may not be 
transferred until another mobile station starts to receive data on the same 
channel. 

In addition the network can also be informed of a need to allocate a TBF 
in the opposite data transfer direction. For example, when uplink TBF is 
allocated, the downlink TBF is also allocated even if no downlink data is to be 
transferred at the moment. This information can be transferred in a signalling 
message as a separate information element or in an information element for 
another purpose. The temporary data flows can also be allocated automatically 
in both data transfer directions (e.g. during a connection establishment phase), 
when the data is a traffic type (e.g. delay sensitive). 
Summary of the Invention 

Application Laver TBF Control 

It is thus an object of the present invention to overcome the problem 
wherein the Temporary Block Flow is released when the data buffer becomes 
empty as specified in the R97 and 99 GPRS RLC/MAC standard (reference [2]). 
This particular problem is with regard to applications where the transmission 
consists of multiple transmission periods separated by silent periods. This is 
particularly a problem for voice service because during a conversation, there are 
often many silent and active periods that vary from milliseconds to tens of 
seconds. According to current specifications, the TBF must separately set up 
for each active period and it is torn down when the silent period begins. This 
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tearing down of the TBF is a problem because the TBF setup procedure Is 
relatively long and it causes unnecessary signalling to occur. Consequently, the 
solution presented in the current GPRS RLC/MAC standard for many applications 
such as voice, telnet, multi-media, etc. is not particularly advantageous. 

Furthermore, currently the Enhanced Data Rates for Global Evolution 
(EDGE), Phase II standardization is in the process of being implemented. There 
is an intensive discussion concerning the design and standardization of 
GSM/EDGE based radio accessed network (EGPRS) that would interface to the 
same core network as Wideband CDMA (WCDMA) based UMTS Terrestrial 
Radio Access Network (UTRAN). In GSM/EDGE RAN real-time voice 
connections are carried over a packet switched radio interface. Thus in order to 
achieve successful use of these technologies for real-time and other traffic type 
applications having inactive periods between active transmission, a method 
must be determined for minimizing the unnecessary tear down of TBF. 

Thus the object of the present invention builds upon the solution 
previously mentioned wherein the RLC/MAC layer is covered. In the present 
invention, the higher level signalling messages are used so as to participate in 
the triggering of a special type TBF setup and as a trigger to participate in the 
release of such a special type TBF. The information is transferred to the lower 
layers through the protocol stack via specific primitives. 

In summary, the present invention is particularly beneficial, and in some 
respects, essential, for data transfer that has active periods and relatively short 
inactive periods. In the case of voice communication being transferred, it is 
extremely important that TBF be kept on all the time in order not to require the 
re-establishment of TBFs over and over again due to pauses in speech. With 
regard to voice communication, TBF establishment would therefore introduce 
too much delay if TBFs were to be released during silent periods and 
consequently the quality of voice communication would be unacceptable. 

In the case of interactive data transfers (such as telnet), delay 
requirements are not the same as with respect to transferring speech since the 
application would continue to operate even if there were slower responses due 
to release of TBF. However by keeping TBF on even when there is nothing to 
send for such an application, results in minimization of common control channel 
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(CCCH) usage (common resource), and packet common control channel 
(PCCCH) and would of course make the usage of telnet in other similar 
applications much more comfortable due to fewer delays before data could be 
transmitted. 

5 Therefore, basically the idea of the present invention is that TBF is not 

released immediately after the radio link control (RLC) buffer becomes empty, 
since some applications, especially speech, require that the communication path 
be maintained even during silent periods. 

Throughout the specification reference is made to delay sensitive data 
1 0 and it should be noted that this refers to a subset of traffic type data which has 
inactive periods between active periods. 

The description contained herein therefore primarily deals with 
transferring data that has relatively short inactive periods (no data to be 
= transmitted) between active periods with delay sensitive real-time data transfer 
1:5 being presented as a particular example of such data transfers. 
I In addition, the enclosed description contains sections specific to delay 

sensitive real-time data transfer. It should further be noted that in UMTS traffic 
' class or traffic type, there typically are four categories; namely, conversational, 
z streaming, interactive and background. Therefore for instance, delay sensitive 
20 real-time data carrying voice could be considered to belong to conversational 
= traffic class. Conversational traffic class has certain requirements with respect 

to data transfer such as low delay and sufficient capacity reservation so as to 
maintain data communication paths even when relatively long time delays occur 
due to e.g. voice silence. Interactive traffic class does not have such strict 
25 delay nor capacity requirements but nevertheless could benefit from such as low 
delay (when there is no need to establish TBFs constantly). 

In GPRS there is no clear division of traffic classes due to the use of 
Quality of Service (QoS) which typically has five different parameters and a 
number of different variations which can be used for adjusting these parameters. 
30 Consequently, the idea set forth herein is that there are different types of 

data that can be categorized into different groups. For example, if UMTS traffic 
class categories are used, voice, real-time video, etc. could be in conversational 
class, whereas video clips or network radio could be in the streaming class, 
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while web browsing and telnet could be in the interactive class and finally, E- 
mail and FTP {file transfer protocol) could be in the background class. However, 
in current GPRS the division is typically different and would be based on the 
defined parameter set so that certain connbinations of QoS bits are interpreted 
as a certain type of traffic (e.g. the interpretation could be that with a specific 
bit combination, real-time data connection is assumed where in between active 
periods there are silent intervals during which there is no data to be transmitted, 
such as for voice communication). Therefore as set forth herein, the new TBF 
release procedure described can be used for a specific traffic type (such as the 
four UMTS traffic classes discussed above), as well as other traffic types that 
use existing or other TBF release modes. In any event, it should be noted that 
any class could be chosen for use with respect to a specific TBF release 
procedure. In addition, it would be feasible that all traffic classes could have a 
new TBF release so that the TBF would be kept on throughout the connection 
(including during silent periods) and would be released only in the event that an 
end of connection with respect to a specific message is received or if a long 
timeout is exceeded (no data packets received for a long period of time). 

Thus the object of the present invention is to provide a method in which 
an application carried over GPRS (such as voice, telnet or web browsing in some 
instances such as streaming audio or video) may trigger a special type of TBF 
wherein the setup and release mode of the TBF may be defined and signalled 
from the upper layer protocol application to the RLC/MAC layer in order to 
participate in the triggering of the TBF control event according to application 
requirements. Therefore applications where transmissions consist of multiple 
transmission periods separated by silent periods do not lose the TBFs seized for 
their use during such silent periods, but instead of unnecessarily releasing the 
TBF, the upper layer protocol can choose a particular type of TBF release mode 
which best suits the application and thus frequent TBF setup and release 
procedures and signalling thereby required are greatly diminished. 

Brief Description of the Drawings 
Figures la 

and lb illustrate a prior art cellular communications system, 
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Figure 1c illustrates a GSM Edge Radio Access Network, 
Figure 2 illustrates protocol levels of a prior art cellular communications 
system. 

Figure 3 illustrates a prior art MAC header in an uplink RLC data block, 
5 Figure 4a illustrates a MAC header in an uplink RLC data block without a TBF 
release indication. 

Figure 4b illustrates a MAC header in an uplink RLC data block with a TBF 
release indication, 

Figure 5 illustrates a flow diagram for the transmission of the uplink RLC 
10 blocks. 

Figure 6 illustrates a flow diagram for the reception of the uplink RLC 
blocks, 

2 Figure 7 illustrates a flow diagram for the transmission of the downlink RLC 
Z blocks, 

f 5 Figure 8 illustrates a flow diagram for the reception of the downlink RLC 

3 blocks, 

" Figure 9 illustrates TDMA frames of active and passive periods of a delay 

J sensitive data flow, 

^ Figure 10 illustrates a block diagram of a mobile station according to the 

20 invention, 

J Figure 11a is a flow chart of TBF setup using a one type of notification method 

according to the present invention. 
Figure lib Is a flow chart of TBF setup using a modification of the notification 
method shown in Figure 11a. 
25 Figure 12 is a flow chart of TBF setup using a snooper method according to 
the present invention. 
Figure 13a Is a flow chart of TBF release using the notification method 

according to the present invention. 
Figure 1 3b is a flow chart of TBF release as a result of a time timeout. 
30 Figure 14 is a diagram that illustrates TBF release using the notification 
method as shown in Figure 13. 
Figure 15 is a flow chart of TBF release using the snooper method according 
to the present invention. 
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Figure 16 is a diagram that illustrates TBF release using the snooper method 
as shown in Figure 1 5. 

Detailed Description 
Introduction 

Figures la, lb and 2 were previously described in the prior art 
description. In the following, principles of indicating specific traffic type (e.g. 
delay sensitive data) and of allocating resources are first described using an 
embodiment in a GRPS system as an example. Next a description is given with 
respect to Temporary Block Flow (TBF) setup and release control at the 
RLC/MAC layer. In this section the placing of the release information into the 
MAC header is described with reference to Figures 3, 4a and 4b. The steps of 
this method are described with reference to Figures 5-9. Then a mobile station 
and a cellular system with respect to this section are described with references 
to Figure 10. The details of the present application layer control of the setup 
and release of Temporary Block Flow (TBF) is then presented with reference to 
Figures 1 la - 16. 

RLC/MAC TBF Control 

In an uplink resource allocation, a mobile station indicates to the network 
that it requires radio resources for specific traffic type (e.g. delay sensitive data) 
transfer. The network needs the information in order to assign sufficient radio 
resources for the mobile station to provide the required service level. The 
information may be provided to the network via one of the following ways, 
where some system specific message denominations are used as examples with 
no intention to limit the applicability of the disclosure: 

The mobile station sends a PACKET CHANNEL REQUEST message 
to the network, and the message is of a specific type that is used 
to identify the specific traffic type (e.g. a delay sensitive data) 
transfer; 

CHANNEL REQUEST DESCRIPTION information element or other 
corresponding information element is included in a PACKET 
RESOURCE REQUEST message and this information element 
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includes information indicating the specific traffic type (e.g. delay 
sensitive data) to be transferred or; 

A priority field or other field is included in the radio resource 
request message, such as a PACKET CHANNEL REQUEST or a 
PACKET RESOURCE REQUEST message, that Is transmitted by the 
mobile station to the network and the field identifies the traffic type 
to be transferred. 

In addition to the information regarding radio resources that are required 
for the specific traffic type (e.g. delay sensitive) data transfer, the radio request 
information may also include the following additional parameters that specify 
more accurately the required resources; 

The number of required packet data channels; 

The information on whether the communication is unidirectional or 
bidirectional. This information makes the network able to 
determine whether the mobile station also requires downlink 
resources. By reserving downlink resources simultaneously with 
the uplink radio resources it is possible to avoid a situation where 
the mobile station would receive downlink data but the network is 
unable to reserve downlink radio resources at that moment; 
First Mechanism - Uplink State Flag (USF): 
When an inactive period begins, the network "polls" (assigns 
sending permission using USF), the mobile station every Nth block 
period whether the mobile station has data to be transmitted or 
not. 

Second mechanism, notification from the mobile station: 
When an inactive period begins, the mobile station notifies the 
network when it has more data to be transmitted. This notification 
is made by sending a control message to the network (e.g. RACH 
message). There is no need for the network to poll the mobile 
station when this mechanism is used. This mechanism therefore 
does not use the concept of N passive block periods. 
Thus there are basically two methods by which a network can receive 
information concerning whether a specific mobile station has become active. In 
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the first method, the network "asks" whether the mobile station has something 
to send. The allocation every Nth block for the user represents this asking 
process. 

in the second method, the mobile station notifies the network that it has 
5 something to send. It can do this such as by using a random access channel 
(RACH channel). 

Thus the MS notification method does not require the allocation of the 
Nth block since the mobile station simply notifies the network when it has data 
to send. In the case where the network "asks" whether the MS has something 
10 to send, the polling or asking if the MS has something to send is used to obtain 
the information as to whether the MS has become active. The USF based 
signalling of uplink transmission permissions is a GPRS specific implementation 
i which is currently being used. Other polling methods could of course be used. 

As the length of the PACKET CHANNEL REQUEST message is only 1 1 or 
is 8 bits, it may be difficult to include the above parameters into the message, 
i Therefore it may be preferable to use two phase (step) access when requesting 

radio resources for specific traffic type (e.g. delay sensitive) data transfer, if a 
^ more accurate description of the requested radio resources is necessary. 

^ There may also be default values for the channel request when one phase 

|o access is used. For example, when requesting radio resources for delay 

sensitive data transfer one packet data channel and only uplink radio resources 
could be reserved as a default. If there is a need to reserve several packet data 
channels the modification of the radio resources can then take place through an 
additional signalling procedure. 
25 In a downlink resource allocation, the procedure starts when the network 

needs to transmit data to the mobile station that has no downlink radio 
resources assigned or when the mobile station requests the establishment of a 
downlink TBF during uplink TBF establishment procedure. The network 
allocates sufficient radio resources based on the information that is attached to 
30 the packet data. The information includes an indication that radio resources are 
required for specific traffic type (e.g. delay sensitive real time traffic) data 
transfer so that the network can assign sufficient radio resources in order to 
provide the required service level. For example, the traffic type requirements of 
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the data may be indicated in an information element included in the Quality of 
Service (QoS) profile. Delay sensitivity of the data transfer may also be 
indicated in a new field in the QoS profile or in a new information element that 
is attached to the data sent from the network, e.g. from a SGSN, to the BSS. 

In addition the following parameters may be included in the information 
that is received from the SGSN in order to describe the required radio resources 
more accurately: 

The number of required packet data channels; 
The information on whether the communication is unidirectional or 
bidirectional. This makes the network able to determine whether 
the mobile station also requires uplink radio resources. By 
reserving downlink resources simultaneously with the uplink radio 
resources it is possible to avoid a situation where the mobile 
station would need to send uplink data but the network is unable to 
reserve uplink radio resources at that moment. 
As discussed above, a USF "polling" technique or a notification technique 
can be used. 

Figure 3 describes a prior art MAC header in an uplink RLC data block 
currently specified in reference [1] (see Table 1). In the header the Paytoad 
Type field indicates the type of data contained in remainder of the RLC/MAC 
block. The Countdown Value field CV is sent by the mobile station to allow the 
network to calculate the number of RLC data blocks remaining for the current 
uplink TBF. This procedure was discussed above. 

The Stall Indicator (SI) bit indicates whether the RLC transmit window of 
the mobile station can advance, i.e. the RLC transmit window is not stalled, or 
whether it cannot advance, i.e. the RLC transmit window is stalled. The mobile 
station sets the SI bit in all uplink RLC data blocks. In RLC unacknowledged 
mode SI is always to be set to '0'. 

The Retry (R) bit indicates whether the mobile station transmitted the 
PACKET CHANNEL REQUEST message once or more than one time during its 
most recent channel access. 

When specific traffic type data (in the above description data having 
inactive periods between active periods) is transmitted from the mobile station 
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to the network the RLC/MAC data block may include a field indicating if the RLC 
block is the last one of the connection or if it is not. This field is called TBF 
Release (TR) in this text. If the RLC block is the last one, the TR field is set to 
value "1 " and the TBF is considered to be released. Otherwise the TR field is 
set to "0" and the network considers the TBF to be open. The TR field may 
replace the stall indicator SI field, because when the RLC operates in 
unacknowledged mode the SI field is not used. The TR field may also be 
included in the CV field by replacing a part of it. 

When such specific traffic type data is transmitted to the network, the 
RLC/MAC data block includes information regarding whether the mobile station 
has more RLC data blocks to be transmitted or if the network may give the next 
N uplink permissions to other mobile stations. 

For example, this information may also be provided to the network in the 
RLC/MAC header and the field is called "CV" herein. The CV field may replace 
all or part of the CV field in the prior art specification. 

In such an example, when the mobile station transfers specific traffic type 
data (data having inactive periods between active periods) to the network and 
CV5^0, the network interprets it to mean that the mobile station has more data 
blocks to be transmitted and the network is thus able to also assign the next 
uplink transmit permissions for the same mobile station. When the CV value is 
set to "0" the network interprets it to mean that the first mobile station has no 
more RLC data blocks to be transmitted at that time and the network may 
therefore give the next N uplink transmit permissions to some other mobile 
station/stations. However, in order to guarantee that the first mobile station 
transferring specific traffic type data does not need to wait too long for an 
uplink transmit permission, the network gives at every N block period an uplink 
transmit period for the first mobile station in case the polling mechanism is used. 
Of course, if the notification mechanism is used, the mobile station notifies the 
network when it has no more data to be transmitted. If the mobile station then 
has RLC data blocks to be transmitted, the mobile station includes RT and CV 
fields in the RLC data blocks as described above. If the mobile station does not 
have data to be transmitted to the network at that time, the mobile station may 


23 


944-003.003 

omit the uplink transmit permission or it may transmit a Packet Dummy Control 
Block or a signalling message. 

If the downlink Temporary Block Flow is also preserved when there is no 
data to be transmitted to the mobile station and if the network is unable to 
determine when to release the downlink TBF, the mobile station should notify 
the network when the downlink TBF can be released. This can be accomplished 
by introducing a bit in the RLC/MAC data block header that indicates whether 
the network is to release both uplink and downlink Temporary Block Flows. The 
mobile station may also transmit a RLC/MAC control signalling message to the 
network indicating the release of downlink Temporary Block Flow prior to the 
release of the uplink Temporary Block Flow. It is also possible to have a timer 
function which would release the downlink Temporary Block Flow after a 
predetermined time has passed from the latest transmission of downlink data. 
The network may contain a logical entity that is able to determine, when the 
TBF is to be released. 

Figure 4a describes an example of the MAC header in an uplink RLC data 
block, without including a downlink TBF release indication. The TBF Release 
(TR) indicates whether the mobile station transferring delay sensitive data 
requests the release of uplink TBF or not. 

Figure 4b describes an example of the MAC header in uplink RLC data 
block including Downlink TBF Release indication DTR in bit 6 of the header. The 
downlink TBF release indicates whether or not the mobile station transferring 
delay sensitive data also requests the release of downlink TBF. The DTR field, if 
used, may be present in all uplink RLC data blocks thus occupying e.g. one 
Count Value CV field bit. DTR field may actually be included in the MAC 
header only when CV field is set to '0' {actually three LSbs) and TR field is set 
to '1', thus leaving 4 bits for CV field in normal operation. 

The parameters as described can be included into the current uplink 
RLC/MAC data block as described above, or a new RLC/MAC data block may be 
defined. If a new data block is defined, the Payload Type may be used for 
identifying the type of the block. 

Figure 5 shows a flow diagram of the steps for transmitting a RLC block 
from a mobile station to the network, 500. The following parameters of a MAC 
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header field are given as examples; many other ways of transferring the 
information can be applied. In step 502, the mobile station checks whether the 
RLC block to be transmitted is the last one in a data block of the TBF. If it is, 
the mobile station sets the parameters CV = 0 and TR= 1 of the MAC header, 
step 504, and transmits the block. The parameter TR= 1 means that the TBF 
can be released, step 506. 

If in step 502 the RLC block is not the last one of the TBF, the mobile 
station checks in step 510, whether the RLC block is the last one in the buffer. 
If it is, the mobile station sets the parameters CV =0 and TR = 0 in step 512 
and transmits the block. This means that the data flow starts a passive period, 
but the TBF is not released. If the RLC block is not the last one in the buffer of 
the mobile station, the parameters are set CV = other than 0 and TR = 0 in step 
520, and the block is transmitted. The CV value can be the number of the 
remaining blocks in the buffer, if the number is small enough to be expressed in 
CV. For example, the CV can be used as the CV parameter in the current 
specification (see ETSI GSM 06.60). 

After the block is transmitted in any of the previous steps, the operation 
is continued from step 500, when there is a data block in the buffer to be 
transmitted, 530. 

Figure 6 shows a flow diagram of the steps for receiving a RLC block 
from a mobile station to the network, 600. In step 602 the network checks the 
value of the TR parameter from the received RLC block. If the parameter TR = 1 , 
the uplink TBF is released, step 604. Next, the release of the downlink TBF 
depends on whether it is requested, steps 606 and 608. 

If in step 602 the parameter TR = 0, the network next checks the value of 
the parameter CV, step 610. If CV =0, this means that there is a passive 
transfer period in the data flow, and the packet data channel may be scheduled 
for another mobile station {other mobile stations), step 612. If, however, the 
parameter CV is different from 0, the channel permission is scheduled for the 
same mobile station, step 620. 

After the block is received and processed in the previous steps, 630, the 
operation is continued from step 600, when there is a new data block received. 
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Figure 7 shows a flow diagram for the transmission of the RLC blocks 
from the network to the mobile station, 700. In step 702, the network checks 
whether the RLC block to be transmitted is the last one in a data block of the 
TBF. If it is, the network sets the parameter Final Block Indicator FBI = 1 . It 
also sets a valid Relative Reserve Block Period (RRBP) field, step 710, and 
transmits the block, step 720. The parameter FBI = 1 means that the current 
block is the last RLC block in the temporary block field and thus the TBF can be 
released. The allocation of a RRBP field means that one uplink transmit block is 
allocated for the receiving mobile station so that the mobile station can send a 
control message to the network indicating the reception of RLC data block with 
FBI = 1. 

If in step 702 the RLC block is not the last one of the TBF, the network 
sets the parameter FBI =0 in step 704. This means that the data flow may or 
may not start a passive period, but the TBF is not released. The network also 
sets a valid RRBP if needed, step 704. 

After this, the network transmits the data block, step 720. After the 
block is transmitted in any of the previous steps, the operation continued from 
step 700, when there is a data block in the buffer to be transmitted, 730. 

Figure 8 shows a flow diagram of the steps for receiving a RLC block 
from the network to a mobile station, 600. In step 602 the mobile station 
checks the value of the FBI parameter from the received RLC block. If the 
parameter FB1 = 1, the downlink TBF release procedure is initiated, step 810. If 
in step 802, the parameter FRI 1 , this means that the mobile station continues 
the receive procedure of the present TBF, step 830. 

Figure 9 shows successive TDMA frames, in which time slot 5 is used for 
a packet data channel. Int he TDMA frames 900 and 902, the packet data 
channel is allocated for an active connection of delay sensitive data transfer. As 
the active period changes into a passive (silent) period, the network assigns a 
transmit permission to a second connection in frame 904. During the passive 
period, frames 904-912, the network also periodically assigns sending 
permissions to the mobile station of the first connection for a channel request, 
frame 908. As the active period starts again, frames 914, 916, the permission 
for an uplink data transfer may be given back to the first connection. If the 
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second connection is transferring delay sensitive data as well, then one of the 
connections may be reallocated to another packet data channel at the beginning 
or at the end of the passive period. 

When the same packet data channel is allocated to several passive 
connections, all the other delay sensitive users can be reallocated to other 
packet data channels when one of them starts transmitting. Alternatively they 
may wait for an uplink transmission permit on the same packet data channel. In 
practice the reallocation may be carried out by sending a signalling message, 
such as a PACKET UPLINK ASSIGNMENT, containing new packet data channel 
allocation to each mobile station being reallocated. Another alternative is to 
send a single signalling message, such as a PACKET REALLOCATION, 
containing new packet data channel allocations to all/some mobile stations being 
reallocated. Using only one signalling message leaves more free radio capacity 
for other purposes. 

When the network receives delay sensitive data for a mobile station, the 
network reserves as much downlink packet data channel capacity to the mobile 
station as is needed. This naturally requires that the network has the needed 
resources available. This may means that the packet data channel is dedicated 
temporarily for a single mobile station in the downlink direction. During the 
passive periods in downlink delay sensitive data transfer the network may 
assign downlink transmission permissions to other mobile stations and thus the 
network can transmit data to other mobile stations. In order to prevent a 
situation where the network receives delay sensitive data to more than one 
mobile station simultaneously on the same packet channel/channels and thus 
would have to block all but one, the network may distribute the other mobile 
stations using delay sensitive data transfer to other packet data channels. The 
distribution can be made using the following mechanisms: 

Early Downlink Assignment 

When the network receives delay sensitive data for a mobile station, it 
reallocates the other delay sensitive data users residing on the same packet data 
channel. Delay insensitive data users may be reallocated to other packet data 
channels or alternatively they will wait for a transmission permit on the same 
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packet data channel. The network transmits a signalling message, such as a 
PACKET DOWNLINK ASSIGNMENT, containing new packet data channel 
allocations to all/some mobile stations being reallocated. 

Late Downlink Assignment 

When the network receives delay sensitive data for a mobile station, it 
does not immediately reallocate the other mobile stations residing on the same 
packet data channel. Only when the network receives delay sensitive data for a 
mobile station and the network is already transferring delay sensitive data to 
some other mobile station on the same packet data channel, does the network 
assign a new packet data channel to the mobile station. The new packet data 
channel is assigned, e.g. by sending a PACKET DOWNLINK ASSIGNMENT 
signalling message to the mobile station. 

The network should ensure that the delay sensitive data does not need to 
queue too long for a downlink transmission permit. The network should also 
ensure that the signalling messages related to the other Temporary Block Flows 
of other mobile stations do not excessively occupy the packet data channel. 
This may be accomplished by giving the same or a higher priority to the delay 
sensitive data transfer compared to signalling messages of other Temporary 
Block Flows. 

When the network temporarily has no delay sensitive data to be 
transmitted, it preserves the Temporary Block Flow and does not set the FBI 
field to value "1 " after transmitting the last buffered RLC data block. The 
mobile station controls the termination of the downlink TBF or the network may 
contain a logical entity that is able to determine, when the TBF is to be released. 

Figure 10 shows a block diagram of a mobile station 100. The mobile 
station comprises an antenna 101 for receiving radio frequency signals from 
base stations. The received RF signal is led with the switch 102 to the RF 
receiver 111, in which the RF signal is amplified and converted digital. 
Thereafter the signal is detected and demodulated in block 112. The type of the 
demodulator depends on the system radio interface. It may include a QAM 
demodulator, or a RAKE combiner. The deciphering and deinterleaving is made 
in block 113. After this, the signal is processed according to the signal type 
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(speech/data). The received packet data can be converted to sound (acoustic 
signal) with a loudspeaker, or the received packet data can be linked to a 
separate device, such as a video monitor. A control unit 103 controls the 
receiver blocks according to a program that is stored into a memory 104. 

In the transmission of a signal, the control unit controls the signal 
processing lock 133 according to the type of signal. Block 121 further makes 
the ciphering and interleaving for the signal. Bursts are formed from the coded 
data in block 122. The bursts are further modulated and amplified in block 123. 
The RF signal is led to the antenna 101 via the switch 102 for transmission. 
The processing and transmission blocks are also controlled by the control unit. 
Especially the control unit controls the transmission blocks in such a way that 
the MAC header parameters of the RLC block are coded and transmitted 
according to the present invention. Also the channel selection is controlled by 
the control unit in such a way that the assigned packet data channel is used 
according to the invention. 

In general, the processing of information in a telecommunication device 
takes place in an arrangement of processing capacity in the form of 
microprocessor{s) and memory in the form of memory circuits. Such 
arrangements are known as such from the technology of mobile stations and 
fixed network elements. To convert a known telecommunication device into a 
telecommunication device according to the invention it is necessary to store into 
the memory means a set of machine-readable instructions that instruct the 
microprocessor{s) to perform the operations described above. Composing and 
storing into memory of such instructions involves known technology which, 
when combined with the teaching herein is within the capabilities of a person 
skilled in the art. On the network side, the features according to the invention 
can be implement e.g. in the Packet Control Unit PCU that assigns e.g. uplink 
and downlink sending permissions for mobile stations. The packet control unit 
may be located e.g. in the Base Transceiver Station BTS, Base Station Controller 
BCS or Serving GPRS Support Node SGSN. 

The information on the following data transfer period can be transferred 
on the packet data channel, or it may be transferred in a signalling message on 
some control channel such as SACCH (Slow Associated Control Channel) of the 
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GSM system. Thus the parameters in a MAC header field of an RLC blocl< are 
given as examples only; many other signalling possibilities exist for transferring 
the corresponding information. Especially the use of the SACCH or a 
comparable control channel will enable the transmission of such information at 
any time, irrespective of whether there is currently an active period or not. 

The above RLC/MAC control of TBF setup and release is not in any way 
restricted to transferring speech data, but it can be applied in a packet radio 
service where any data flows with passive and active periods are transferred. 
One example is video data transfer, wherein a moving/changing video image 
would require an active data flow and still video image periods which would not 
require data transfer for the image update. The invention is also applicable to 
various Internet uses, such as telnet interaction with a remote computer. 

The above description sets forth an exemplary embodiment of the 
RLC/MAC layer control of TBF for real-time data transfer. This TBF control is 
used at the lower layers for the application layer control of TBF as are fully 
described below. 

Application Level Control of TBF 

The present invention is directed to control of Temporary Block Flow 
(TBF) at the application level of a multi-level communication over general packet 
radio service (GPRS). It is particularly directed to applications which have the 
need for inhibiting the release of TBF during passive or silent periods which may 
exist during the execution of the application. Such applications include voice 
applications, telnet interaction with remote computers over the Internet as well 
as web browsing over the Internet. 

According to the invention, the application participates in the setup and 
release of TBF such that TBF may be defined and signalled from the upper layer 
protocol application to the RLC/MAC layer so as to trigger a TBF control event 
according to application requirements, rather than to release TBF during the 
occurrence of a silent or passive period. In summary, the application 
communicates Information to the RLC/MAC layer so that based upon this 
information a special type TBF is set up or released. The RLC/MAC layer 
implementation of TBF setup and release is as described above. 
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In particular, different types of call control signalling can be used to set 
up radio bearers and an end-to-end connection between two users. For 
example, in voice communication over GSM/EDGE RAN (EGRS) H.323 or SIP, 
signalling can be used. It is also noticed, that other connection control 
signalling exists and can be used e.g. described in ETSI GSM 04.08 call control 
specification. 

TBF Setup 

When the mobile station (user) starts a voice connection, a certain type of 
packet data protocol (PDF) context is required from the network. From this 
context information or from the sent signalling message, the existence of voice 
or other real-time traffic type application can be determined. Such information 
can be communicated to the RLC/MAC layer through the protocol stack in 
conjunction with a special type of TBF (in one implementation the TBF may be 
the same as that used in other applications). This special type of TBF is 
relevant because not only does the upper layer application participate in causing 
it to be set up, but also because this special type TBF is released when the 
upper layer application signals that it can be released. Thus the application 
participates in controlling the duration of the TBF. 

TBF may be established beforehand when there is still no data to be 
transmitted. TBF may also be established only at the same time when the first 
data packets arrive at the RLC.MAC layer. The special type of TBF prevents the 
radio connection from being released even though capacity with respect to the 
radio connection may be given to other mobile stations as set forth in the 
above-described control of TBF at the RLC/MAC layer. For certain applications, 
the PDP type context uses normal TBF procedures with respect to setup and 
release as described in the TBF setup and release section. 

It should be noted that there may be a plurality of special type TBFs. 
Thus a particular special type TBF may be determined by the application 
according to the context or the data information that the application intends to 
transmit/receive. For each such special type TBF, the TBF will be on during 
both active and passive periods, or the TBF may be chosen by the application to 
be on when the application requires transfer resources. 
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Notification Method 

As best seen in Figure 1 1 a, when an application transfers specific traffic 
type data (e.g. real-time data which has inactive periods), the application 
notifies GPRS elements (protocols) in order to initiate a set up of a special type 
of TBF that uses a TBF release mechanism as set forth in the above described 
RLC/MAC TBF section. In a simple embodiment, only one TBF release with no 
alternatives is available. In such an embodiment the mobile station only relays 
data and does not communicate with user applications. 

Referring again to Figure 11a, the application first determines that it will 
require specific traffic type data transfer (step 1900). The application may 
notify GPRS elements of the special type of TBF setup immediately (step 1910). 
As seen in Figure 1 1 b, the application can notify GPRS elements after specific 
traffic type transfer is about to begin (steps 1912, 1910, 1916) in which 
situation, the connection does not require a specific traffic type transfer 
characteristic to be established before actual specific traffic type data transfer is 
to occur. In either situation, the application may send e.g. a special message 
to the GPRS element using the same path as used by the data messages (path 
1903, 1905, 1907; 1909, 1911, 1913, 1915), wherein at least a specific 
format is used for a data packet for notifying the GPRS element (of the special 
message) or the application may use a specific control path (1925; 1927) 
currently used for such purposes as activating and deactivating PDP context etc. 
(such as the use of the attention-AT-commands). 

When GPRS elements receive notification that can be interpreted as a 
need to initiate a special TBF setup, the information is transferred to the 
RLC/MAC (step 1916) to insure that the RLC/MAC receives this information 
even if a direct connection is not made between the RLC/MAC and the 
application. Such a situation could occur where the application communicates 
with GPRS MM (Mobility Management) layer. The RLC/MAC then initiates the 
special type of TBF setup (step 1918) using the procedures as set forth above 
with regard to RLC/MAC TBF setup and release. 

In all these situations, the present invention provides for the application 
executing at the application level to determine the chosen special type TBF 

32 


944-003.003 


associated with a corresponding TBF release mode so as to optimize 
communications using GPRS for traffic type data transfers. 
Snooper Metliodology 

As best seen in Figure 12, in some implementations of GPRS, a snooper 
is present, which in fact is an element that can observe data traffic as it is being 
transferred. The snooper element may be included in a GPRS element (protocol) 
or it may be located between the application and the GPRS elements. It can 
even be located in the application itself. 

As seen in Figure 1 2, the mobile station application generates data 
packets such that data packets which require data transfer of a specific traffic 
type have a unique identification associated with these packets (step 1950). 
The packets are observed by the snooper (step 1952) and continue on to their 
intended destination (step 1954). If the snooper element determines that the 
application contains specific traffic type data (step 1956), the snooper notifies 
the RLC/MAC of the traffic type data transfer (step 1958) and the RLC/MAC 
then sets up the special type of TBF as described earlier (step 1960). In a 
simple embodiment, only one TBF type may be used by the system. As stated 
earlier, the snooper may be located within the MS application itself or it may be 
located in the RLC/MAC layer. Notification to the RLC/MAC layer occurs if the 
snooper is not located in this layer. 

This snooper element thus is also able to observe the data packets being 
sent to the application, as well as the data packets being generated by the 
application. The snooper element is able to interpret the contents of the data 
packets being transferred and thereby knows if the application is generating a 
specific traffic type of data packet indicative of data that has inactive periods 
between active periods. When the snooper notices a special format data packet 
(e.g. a special packet the application/protocol uses to establish connection with 
its peer entity), the snooper participates in the initiation of the special type of 
TBF establishment procedure using the RLC/MAC layer. 

In one simple implementation, the RLC/MAC layer observes the Quality of 
Service (QoS) related associated parameters with messages received from the 
application. Normally the first data packet is observed and if this data packet 
header contains special types of information indicative of a specific traffic type 

33 


944-003.003 

data transfer, the special TBF is setup by the RLC/MAC in a manner as 
described above. Again in a simple embodiment, only one TBF type may be 
used by the system. 

TBF Release 

5 When a certain type of higher layer signalling message (such as H.245 

endSessionCommand or TCP/IP FIN COMMAND) is received, the information is 
communicated through the protocol stack to the RLC/MAC layer where the TBF 
is released (torn down). The releasing or tear down of the TBF may occur only 
in one direction (such as uplink) or in cases where there are TBFs in both 
10 directions, both TBFs (uplink and downlink) may be released (torn down) 

simultaneously as described above with regard to RLC/MAC TBF setup and 
a release. The termination of TBFs can be communicated to the peer as part of an 

I RLC data block or it can be communicated in a separate signalling message. 

3 There must also be a mechanism to release TBF if the message that 

JjS contains such release information is lost. In view of this situation, there is a 
^3 timer (see Timer step 1014 in Figures 1 3b and 1 5) that releases the TBF if the 

□ RLC/MAC buffer is empty in excess of a predetermined length of time. 

:= Notification Method 

fi TBF release can be communicated with a notification method. As seen in 

20 Figure 13a, when there is no more specific traffic type data to transfer or when 
the session has ended (set 1980), the application notifies the GPRS element of 
this application status (step 1982). The application may inform the GPRS 
element of this status by generating a special message to the GPRS element 
using the same path (1981) as that used for data messages (wherein a special 
25 format is used for the data packet containing such information) or the 

application may use a specific control path (1983) which is currently used for 
other purposes such as for activating and deactivating PDF context, etc. (such 
as AT commands). In such a situation it should be noted that it is permissible 
and relevant that the application control the GPRS protocol stack. 
30 When the GPRS elements receive notification to initiate TBF release 

procedure, this information is transferred to the RLC/MAC layer in case the 
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application and the RLC/MAC do not comnnunicate directly to each other (step 
1984). Again, the procedures as described earlier with regard to RLC/MAC TBF 
setup and release are used for purposes of releasing the special type of TBF. 

Figure 1 3b illustrates that ail packets generated by the MS application 
(step 1985) are observed by a timer function (step 1014) and if no packets are 
seen for some predetermined length of time, a timeout occurs and the special 
type TBF is released (step 1016). If the timeout does not occur the packets 
proceed to their destination (step 1987). 

Figure 14 illustrates the notification of the special type of TBF release for 
the notification method described from the application layer to the RLC/MAC 
layer. 

Snooper Method 

A snooper element is one which observes data traffic as the data traffic is 
transferred. Such an element may be included in GPRS elements (protocols) or 
it may be located between the application and GPRS elements or in the 
application itself. If the snooper element is not located in the RLC/MAC layer, 
the snooper element uses mechanisms as described above with regard to setup 
and release of TBF in order to notify the RLC/MAC of TBF release. The snooper 
methodology is best seen with reference to Figure 15. As seen in Figure 13, 
the mobile station can generate data packets (step 1000). The snooper element 
observes these data packets to determine if a special format data packet 
indicative of release of TBF (e.g. TCP/IP FIN command) has been received (step 
1010). If a special format data packet has been received (step 1012) the 
snooper element initiates release of TBF as shown by (step 1020) while the 
packets (if any) are transferred to the intended destination (step 1022). If a 
special format data packet has not been received, the packets continue on to 
their destination (step 1020). As indicated, the special data packet indicative of 
release of TBF can be a data packet that the application uses in connection to 
its peer entity, such as the H.245 endSessionCommand or the TCP/IP FIN 
command. Thus the snooper element observes data packets being sent and 
received and is able to interpret the contents of the data packets being 
transferred; that is, it knows the protocol/application being used. By so doing, it 
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can perform the examination as described above in order to initiate release of 
TBF upon determination of receipt of a special packet indicative of such release. 

In addition, as seen in Figure 1 5, a timer step (step 1014), observes the 
flow of data packets. If data packets are not present for some predetermined 
5 length of time, the timer initiates release of TBF (step 1016). This timer 

function is a watchdog type function in case the application fails to generate the 
special type of data packet indicative of TBF release. Consequently, 
applications can start transmitting data over the radio interface after becoming 
active without having to wait for TBF setup, while on the other hand when the 
10 session ends, the TBF (and thus the Temporary Flow Identity - TFI) can be 

released immediately and not after some timeout has occurred according to the 
methodology previously discussed. 

Figure 1 6 illustrates the snooper special type of TBF release method from 
- the application layer to the RLC/MAC layer. 

1^5 In the above examples, the solution for generating a special type of TBF 

z by means of the application is optimal for e.g. real-time data which has multiple 

active periods separated by inactive periods (e.g. voice communication). It may 
= also be useful e.g. for web browsing and telnet type connections. 
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It is readily apparent to those skilled in the art that the objects set forth 
above have been officially attained, and since certain changes may be made in 
carrying out the above method without departing from the scope of the 
invention, it is intended that all matter contained in the above description or 
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shown in the accompanying drawings shall be interpreted as illustrative and not 
in a limiting sense. 

It should also be understood that the following claims are intended to 
cover all of the generic and specific features of the invention herein described, 
and all statements of the scope of the invention which, as a matter of language, 
might be said to fall therebetween. 
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What Is Claimed Is : 

1 1 . A method for transferring a data flow according to a multi-layer protocol 

2 Including an application layer in which an application is executing, and a plurality 

3 of lower level layers, the method of transferring data flow by creating a physical 

4 connection on a packet radio service of a telecommunication system including a 

5 network and at least one mobile station, said physical connection for 

6 transferring data packets on a packet data channel, wherein the data flow of 

7 said data packets comprises at least one active data transfer period, 

8 characterized in that the physical connection must be set up and released by 

9 setup and release information that defines and signals the set up and release of 

10 the physical connection, and wherein the set up and release of the physical 

1 1 connection is defined and signaled from the application executing in the 

^ 2 application layer to a lower level layer of the multi-layer protocol so that the 

1 3 control events for setup and release of the physical connection are based upon 

14 requirements of the application that is executing in the application layer. 

1 2. A method according to claim 1, characterized in that the lower level layer 

2 that receives said setup and release information from the application executing 
= 3 in the application layer is the radio link control/medium access control 

= 4 (RLC/MAC) layer. 

1 3. A method according to claim 1, characterized in that the lower level layer 

2 that receives said setup and release information from the application executing 

3 in the application layer is the radio link control (RLC) layer. 

1 4. A method according to claim 1 , characterized in that the lower level layer 

2 that receives said setup and release information from the application executing 

3 in the application layer is the medium access control (MAC) layer. 

1 5. A method according to claim 1, characterized in that the setup and 

2 release information is transferred on the packet data channel. 
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1 6. A method according to claim 1 , characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application, wherein at least part of the context information is 

4 communicated to a radio link control/medium access control (RLC/MAC) layer 

5 through the protocol stack; wherein the physical connection is not released 

6 during an inactive period if the application executing in the application layer is 

7 determined to be a specific traffic type application. 

1 7. A method according to claim 6, characterized in that the data flow is 

2 arranged to consist of data blocks, and said setup and release information is 

3 transferred in a header of a data block. 

1 8. A method according to claim 7, characterized in that the radio service is 

2 GPRS and the header is a MAC header of an RLC block. 

1 9. A method according to claim 1, characterized in that the radio service is 

2 GPRS and further characterized in that if the application executing in the 

3 application layer transfers specific traffic type data, the application notifies 

4 GPRS protocols in order to set up a Temporary Block Flow (TBF) of a special 

5 type that will not be released if an inactive period occurs that is less than a 

6 predetermined amount. 

1 10. A method according to claim 9, wherein there is a set of special type 

2 TBFs, and wherein the application sets up a special type TBF based upon 

3 requirements of the application. 

1 11. A method according to claim 9, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF upon initialization of the application. 

1 12. A method according to claim 1 1 , characterized in that the application 

2 executing In the application layer notifies the GPRS protocol of the special type 
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3 of TBF by using the same path as for data messages generated by the 

4 application. 

1 13. A method according to claim 12, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 14. A method according to claim 1 1, characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application executing in the application layer, wherein at least 

4 part of the context information is communicated to a radio link control/medium 

5 access control (RLC/MAC) layer through the protocol stack; further 

6 characterized in that the application notifies the GPRS protocol of the special 

7 type of TBF by using a specific control path used for activating and deactivating 

8 the PDP. 

1 15. A method according to claim 14, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 1 6. A method according to claim 9, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF only when a specific traffic type transfer is about to start. 

1 17. A method according to claim 16, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF by using the same path as for data messages. 
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1 18. A method according to claim 13, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 1 9. A method according to claim 1 6, characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application executing in the application layer, wherein at least 

4 part of the PDP context is communicated to a radio link control/medium access 

5 control (RLC/MAC) layer through the protocol stack; further characterized in that 

6 the application notifies the GPRS protocol of the special type of TBF by using a 

7 specific control path used for activating and deactivating the PDP. 

1 20. A method according to claim 1 6, characterized in that the method of 

2 transferring data flow requires initialization of a packet data protocol (PDP) 

3 before the application is executed, wherein at least part of the PDP context 

4 information is communicated to a radio link control/medium access control 

5 (RLC/MAC) layer through the protocol stack; further characterized in that the 

6 application notifies the GPRS protocol of the special type of TBF by using a 

7 specific control path used for activating and deactivating the PDP. 

1 21. A method according to claim 19, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 22. A method according to claim 1 9, wherein the control path may be 

2 different for setup and release of the TBF. 
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1 23. A method according to claim 10, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF upon initialization of the application. 

1 24. A method according to claim 23, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF by using the same path as for data messages generated by the 

4 application. 

1 25. A method according to claim 24, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 26. A method according to claim 23, characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application executing in the application layer, wherein at least 

4 part of the PDP context information is communicated to a radio link 

5 control/medium access control (RLC/MAC) layer through the protocol stack; 

6 further characterized in that the application notifies the GPRS protocol of the 

7 special type of TBF by using a specific control path used for activating and 

8 deactivating the PDP. 

1 27. A method according to claim 26, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 28. A method according to claim 10, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF only when a specific traffic type transfer is about to start. 
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1 29. A method according to claim 28, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF by using the same path as for data messages. 

1 30. A method according to claim 25, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 31 . A method according to claim 28, characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application executing in the application layer, wherein at least 

4 part of the PDP context information is communicated to a radio link 

5 control/medium access control (RLC/MAC) layer through the protocol stack; 

6 further characterized in that the application notifies the GPRS protocol of the 

7 special type of TBF by using a specific control path used for activating and ■ 

8 deactivating the PDP. 

1 32. A method according to claim 28, characterized in that the method of 

2 transferring data flow requires initialization of a packet data protocol (PDP) 

3 before the application is executed, wherein at least part of the PDP context is 

4 communicated to a radio link control/medium access control (RLC/MAC) layer 

5 through the protocol stack; further characterized in that the application notifies 

6 the GPRS protocol of the special type of TBF by using a specific control path 

7 used for activating and deactivating the PDP. 

1 33. A method according to claim 31, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 
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1 34. A method according to claim 1 , characterized in that the radio service is 

2 GPRS and further characterized in that if the application executing in the 

3 application layer transfers specific traffic type data, the application notifies 

4 GPRS protocols in order to set up a Temporary Block Flow (TBF) that will not be 

5 released if an inactive period occurs that is less than a predetermined amount. 

1 35. A method according to claim 34, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF upon initialization of the application. 

1 36. A method according to claim 35, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF by using the same path as for data messages generated by the 

4 application. 

1 37. A method according to claim 36, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 38. A method according to claim 35, characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application executing in the application layer, wherein at least 

4 part of the PDP context information is communicated to a radio link 

5 control/medium access control (RLC/MAC) layer through the protocol stack; 

6 further characterized in that the application notifies the GPRS protocol of the 

7 special type of TBF by using a specific control path used for activating and 

8 deactivating the PDP. 

1 39. A method according to claim 38, wherein the GPRS protocol upon 

2 receipt of notification to set up a special type of TBF, transfers the notification 

3 to the RLC/MAC layer to ensure that the RLC/MAC initiates the special type of 
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4 TBF even if the application executing in the application layer does not 

5 communicate directly with the RLC/MAC layer. 

1 40. A method according to claim 34, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF only when a specific traffic type transfer is about to start. 

1 41 . A method according to claim 40, characterized in that the application 

2 executing in the application layer notifies the GPRS protocol of the special type 

3 of TBF by using the same path as for data messages. 

1 42. A method according to claim 37, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 43. A method according to claim 40, characterized in that the method of 

2 transferring data flow requires generation of a packet data protocol (PDP) upon 

3 initiation of the application executing in the application layer, wherein at least 

4 part of the PDP context information is communicated to a radio link 

5 control/medium access control (RLC/MAC) layer through the protocol stack; 

6 further characterized in that the application notifies the GPRS protocol of the 

7 special type of TBF by using a specific control path used for activating and 

8 deactivating the PDP. 

1 44. A method according to claim 40, characterized in that the method of 

2 transferring data flow requires initialization of a packet data protocol (PDP) 

3 before the application is executed, wherein at least part of the PDP context is 

4 communicated to a radio link control/medium access control (RLC/MAC) layer 

5 through the protocol stack; further characterized in that the application notifies 

6 the GPRS protocol of the special type of TBF by using a specific control path 

7 used for activating and deactivating the PDP. 
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1 45. A method according to claim 43, wherein the GPRS protocol upon receipt 

2 of notification to set up a special type of TBF, transfers the notification to the 

3 RLC/MAC layer to ensure that the RLC/MAC initiates the special type of TBF 

4 even if the application executing in the application layer does not communicate 

5 directly with the RLC/MAC layer. 

1 46. A method according to claim 1 , characterized in that the application 

2 executing in the application layer generates a special format data packet that 

3 designates that the physical connection is not to be released upon the 

4 occurrence of an inactive period less than predetermined amount, further 

5 characterized in that the data packets generated by the application are observed 

6 by a special protocol (snooper) such that if said special format data packet is 
"7 observed, a special type of Temporary Block Flow (TBF) is set up. 

1 1 47. A method according to claim 1 , characterized in that the application 

1 2 executing in the application layer generates a special format data packet that 
=,3 designates that the physical connection is not to be released upon the 

4 occurrence of an inactive period less than predetermined amount, further 

= 5 characterized in that the data packets generated by the application are observed 

6 by a special protocol (snooper) such that if said special format data packet is 

7 observed. Temporary Block Flow (TBF) is set up. 

1 48. A method according to claim 46, characterized in that the application 

2 generates a special format data packet that contains a quality-of-service (QoS) 

3 parameter in the RLC/MAC header of the first generated data packet by said 

4 application executing in the application layer. 
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Abstract of the Disclosure 

A method as described by which an application executing in an 
application layer of a multi-layer communication protocol forming part of a 
general packet radio service (GPRS) session can signal for the setup and release 

5 of Temporary Block Flow (TBF) which will not be released during application 

execution in silent (inactive) periods. When applications such as voice, telnet or 
web browsing have specific traffic type data that have inactive periods between 
active periods are to be carried over GPRS, the session consists of multiple 
active periods. Current TBF release procedures lead to multiple TBF setups 

0 during such sessions. With the method described, a special type of TBF can be 
set up with special procedures for release of this TBF which greatly minimizes 
the need for multiple TBF setups during a session containing data transfers with 
inactive periods between active data transmissions. 
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specific traffic type data transfer. 
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RLC/MAC sets up TBF (may be 
special type TBF or one special 

type of a set of special type 
TBFs). 
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RLC/MAC sets up TBF (may be 
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RLC/MAC initiates release of TBF 
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TBFs). 
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Initiate release of TBF (may be 
special type TBF or one special type 
of a set of special type TBFs). 
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Snooper observes data packets to 
determine if special format data 
packet indicative of release of TBF 
(e.g. TCP/IP FIN command) 
received. 
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